The present invention relates to communicating services to a terminal, which services relate to an application stored in a microcontroller card, also referred to as a “smart card” or as an “integrated circuit card”.
The terminal receives the smart card and can, in a first example, be a mobile radio terminal for which the smart card is of the Universal Integrated Circuit Card (UICC) type. For example, the smart card is a Subscriber Identity Module (SIM) for a cellular radiocommunications network of the Global System for Mobile Communications (GSM) type, or a Universal SIM (USIM) for a Code Division Multiple Access (CDMA) network of the third generation (3rd Generation Partnership Project (3GPP)) of the Universal Mobile Telecommunications System (UMTS) type. In other examples, the terminal can be a bank terminal receiving a debit or credit card, or a Personal Computer (PC) equipped with a smart card reader, or indeed a small item of communicating equipment such as a Personal Digital Assistant (PDA) that can read a smart card inserted into it.
In general, a microcontroller card that implements one or more applications, each of which is associated with one or more services cannot transmit data relating to the services proposed by an application directly to the terminal. The link between the terminal and the card is a master-slave link in which the terminal is the master and the card is the slave. The data exchanged between the card and the terminal is exchanged using a dedicated communications protocol in compliance with the ISO 7816-3 Standard. The card uses a mechanism of the proactive type in order to trigger actions in the terminal which periodically interrogates or “polls” the card.
In that type of link, the terminal discovers itself the services that can be offered by the card. Then the card must wait for a command from the terminal relating to the service of the application that the terminal wishes to use, in order to transmit the data of said service to the terminal, which data is stored in the card. The command from the terminal is established under the control of the user of the terminal, or of an entity from the world outside the card connected to the terminal.
As shown in FIG. 1, a known method for communicating services between the card and the terminal comprises steps E1 to E8.
The first step E1 indicates that a user of the terminal or the terminal itself, into which the microcontroller card is inserted, wishes to access a service of an application stored in the card. The terminal, acting as a customer, transmits a command to the card for having the application selected in step E2. This command is, for example, the standardized “SELECT” command. Following the command, the card transmits, in step E3, an acknowledgement status message to the terminal for the purpose of acknowledging the command of the terminal. The first status message comprises header fields only; e.g. the first message includes two bytes indicating that the command has succeeded, i.e. that the application exists in the card, or that the command has failed, i.e. that an anomaly has occurred or that the application is absent from the card. The first status message is, for example, the hexadecimal value 0x9000 in compliance with the ISO 7816 Standard. The message does not include any data field to be transmitted to the terminal so long as said terminal has not requested such data. In the next step E4, the terminal interrogates (polls) the card about its status periodically, e.g. every 500 milliseconds (ms). If the card wishes to transmit data to the terminal, the card transmits to the terminal, during step E5, a second status message that indicates that the card has one or more services to be declared in relation to the application. The second status message is, for example, the hexadecimal value 0x61xx in compliance with the ISO 7816 Standard. On receiving said second message, the terminal transmits to the card a command asking the card to transmit data identifying the service(s) of the application, in step E6. That command is, for example, the standardized ISO 7816 “GET RESPONSE” command. Then, in step E7, the card transmits identification data for identifying the service(s) in one or more messages having a status header.
So long as the service identification data is not disclosed to the terminal, the card cannot dispense the service(s) of the application. Once said data has been transmitted to the terminal, the card no longer transmits it until the next update (reset) of the service(s) of the application.
This method requires a plurality of command and response steps E2 to E7 between the terminal and the card in order for the card to transmit data relating to the services of an application to the terminal. The intermediate steps E3 to E6 defer the communication of the service data from the card to the terminal and more generally to the world outside the card. If the application offers a multitude of services, a plurality of messages are often necessary for identifying the services, thereby deferring communication of the data by a corresponding length of time.
In another known method implemented in banking systems, available applications are communicated by a microcontroller card of the Europay Mastercard Visa (EMV) type to a terminal. Like the preceding method, that method requires a plurality of command and response exchanges between the terminal and the card in order for the card to transmit data relating to the applications to the terminal.